REMARKS 

Claims 1-8 stand rejected under 35 U.S.C. 103(a) as being obvious over Chen 
et al. (U.S. Patent No. 5,553,235) in view of Gerardin et al. (U.S. Patent 6,222,822), and 
further in view of Adl-Tabatabai (U.S. Patent No. 6,170,083). In response. Applicants have 
amended claims 1 and 6-8 to further clarify that the "utility rate" is a "utility rate ratio" and 
that the system diagnosis apparatus transmits, to the computer system, information including 
upgrade reconraiendation information for replacing or adding to a system resource that is 
diagnosed to have low performance, and respectfully traverse the rejection. Applicants 
respectfully traverse the rejection because the cited references, taken alone or in combination, 
do not disclose or suggest, among other things, a utility rate ratio and a diagnosis system that 
transmits information recommending a corrective action for upgrading a poorly performing 
system resource, as now recited in amended claims 1 and 7-8. 

The Chen et al. reference discloses a method and apparatus for analyzing the 
operations of data processing systems, where a user can graphically determine performance 
diagnostics for the data processing system. As indicated by the Examiner, the Chen et al. 
reference fails to explicitly state that the diagnosis of the performance of the system consists 
of a system resource being lowered when a utility rate is higher than a threshold of a utility 
rate and a queue length is shorter than a threshold of the queue length, or diagnosis that the 
number of system resources is insufficient when the utiUty rate is higher than the threshold of 
the utility rate and the queue length is longer than a threshold of the queue length. Moreover, 
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the Chen et al. reference does not disclose or suggest a ratio of a utiUty rate, or an apparatus 
or method that acquires a utility rate ratio of the system resources. That is, it does not 
disclose or suggest storing thresholds of the utility rate ratio, or diagnosing a performance of 
the system resource is lowered when the utility rate ratio is higher than the threshold of the 
utility rate ratio and a queue length is shorter than a threshold of the queue length, or 
diagnosing that the number of system resources is insufficient when the utility rate ratio is 
higher than a threshold of the utility rate ratio and a queue length is longer than a threshold of 
the queue length. 

Chen et al. discloses displaying results of a diagnosis using data received from 
a data source through a network, as illustrated in FIGs. 12a-12e where data is graphically 
recorded in memory. Chen et al. does not disclose or suggest a system for diagnosing a 
system. Since the Chen et al. reference does not acquire, store, or diagnose the utility rate 
ratio, and also does not transmit information including upgrade recommendation information 
for replacing or adding to a system resource that is diagnosed to have low performance to a 
computer system, Applicants submit that it would not have been obvious to combine the steps 
recited above in combination with transmitting a recommendation for improving system 
resources based on the teaching of the Chen et al. reference. 

The Gerardin et al. reference discloses a method for optimizing a digital 
transmission network operation through transient error monitoring, and has a threshold set for 
a transmit queue whose level is constantly monitored by using a counter. A re-routed 
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connection is provided if a transient error occurs in one of the queues and the connection is 
disabled (CoL 9, Ins. 23-44). A queue threshold control (TC) mechanism 53 monitors the 
queue level verses the assigned threshold for the specific queue considered. The mechanism 
includes a queue counter which keeps track of the queue level by being incremented when a 
data packet is enqueued and decremented when a data packet leaves the queue for 
transmission over an output link. When the queue threshold is reached, and the XP3 memory 
resources are in depletion, a special purpose processor implementing transport queue level 
control indicates that the queue level is high and sets a Discard bit that is used to close a gate 
of a Data Packet Admission mechanism 51 and discard the queue incoming packets from a 
corresponding queue (Col. 9, In. 54 through Col. 10, In. 9). 

While the Gerardin et al. reference discloses an optimizing method for transient 
errors, it does not disclose a utility rate ratio. In addition, the Gerardin et al. reference does 
not disclose acquiring a utility rate ratio, storing the utility rate ratio, and diagnosing the 
performance of a system resource as lowered based on a utility rate ratio and a queue length. 
Therefore, since the Gerardin et al. reference does not acquire, store, or diagnose the utility 
rate ratio. Applicants submit that it would not have been obvious to combine these steps 
based on the teaching of the Gerardin et al. reference. Furthermore, the Geradin et al. 
reference does not disclose or suggest transmitting, to a computer system, information that 
includes upgrade reconraiendation information for replacing or adding to a system resource 
that is diagnosed to have low performance, as now recited in the claims. 
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The Adl-Tabatabai reference discloses a method for optimizing execution 
paths, where an execution path is optimized when the execution path is executed often (Col. 
5, Ins. 18-27). The number of executions are counted by an execution path counter, and if the 
execution path counter exceeds a threshold value, than the execution path is optimized so that 
the optimized execution path contains no branches such that the optimized execution path 
will execute very quickly (Col. 6, Ins. 19-37). The Adl-Tabatabai reference does not disclose 
or suggest the use of a utility rate ratio. Rather, as illustrated in Fig. 4, after each region of 
code is executed at a step 460, the method then determines whether or not a Java program has 
completed execution at a step 465. If the program has completed execution, then the 
program is completely done. If not, then an execution path counter associated with the 
followed execution path is incremented at a step 470, The counter associated with the taken 
execution path is compared with the threshold value at a step 480. If the execution path 
counter exceeds the threshold value, as previously stated, then the followed execution path is 
optimized at a step 490, where an optimizing compiler generates an optimized set of code for 
that particular execution path (Col. 6, Ins. 19-28 and 57-61). 

While the Adl-Tabatabai reference discloses a threshold level, it does not 
disclose a utility rate ratio, or an apparatus, medium, or method which includes acquiring a 
utility rate ratio, storing the utility rate ratio, or diagnosing that the performance of a system 
resource has lowered based on the utility rate ratio and a queue length. Accordingly, since 
the Adl-Tabatabai reference does not acquire, store, or diagnose the utility rate ratio, 
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Applicants submit that it would not have been obvious to combine these steps based on the 
teaching of the Adl-Tabatabai reference. Moreover, the Adl-Tabatabai reference does not 
disclose or suggest transmitting, to a computer system, information including upgrade 
reconraiendation information for replacing or adding to a system resource that is diagnosed to 
have low performance, as now recited in the claims. 

In contrast, the present invention has a feature of diagnosing system resources 
of a computer system, and transmitting, to the computer system, information in response to 
the diagnosis including upgrade recommendation information for replacing or adding a 
system resource that is diagnosed to have low performance. In addition, claims 1 and 7-8 
now call for, among other things, acquiring information on a utility rate ratio of the system 
resources and a queue for the system resources, storing thresholds of the utility rate ratio and 
the queue, and diagnosing the performance of the system resources as lowered when the 
utiUty rate ratio is higher than the threshold of the utility rate ratio and the queue length is 
shorter than a threshold of the queue length, or that the number of system resources is 
insufficient when the utility rate ratio is higher than a threshold of the utility rate ratio and a 
queue length is longer than the threshold of the queue length. That is, the present invention 
discloses on pg. 10, Ins. 20-22 that a CPU utiUty rate is a ratio of run time of the CPU 
executing the program to the measuring time required for measurement of a CPU utility rate 
(run time/measuring time). Also disclosed on pg. 1 1, Ins. 14-17 of the present invention is a 
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disk utility rate that is the ratio of an operating time required for read/write operation to a 
measuring time required for measuring a disk utiUty rate (operating time/measuring time). 

Since the cited references, taken alone or in combination, do not disclose or 
suggest a utility rate ratio, let alone the steps of acquiring, storing, or diagnosing a utility rate 
ratio, in combination with transmitting, to a computer system, information that includes 
upgrade reconmiendation information for replacing or adding to a system resource that is 
diagnosed to have low performance, Applicants respectfully request withdrawal of the §103 
rejection to amended claims 1 and 7-8. 

Since claims 2-6 ultimately depend upon claim 1, they necessarily all of the 
features of their associated independent claim plus other additional features. Thus, 
AppUcants submit that the § 103 rejection of claims 2-6 has also been overcome for the same 
reasons mentioned above to overcome the rejections of independent claim 1. Applicants 
respectfully request that the §103 rejection of claims 2-6 also be withdrawn. 
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For all of the above reasons, Applicants request reconsideration and allowance 



of the claimed invention. The Examiner should call Applicants' attorney if an interview 
would expedite prosecution. 
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